%-----------------------------------------------------------------------------
\chapter{Umsetzung}
%-----------------------------------------------------------------------------


%Haui das hier nicht vergessen denn das ist wichtig für deine Arbeit.
%Damit sie nicht wertlos ist.
%http://docs.oracle.com/javaee/6/tutorial/doc/gjiie.html



\section{Gewählte Umsetzung}
%Haui so ein G'setzerl noch bei jedem Kapitel dazuschreiben.
Aufgrund der definierten Zielsetzung und der damit verbundenen Kriterien werden
folgende Technologien für die Umsetzung herangezogen.


\subsection{Java EE Applikationsserver} 
Um zu zeigen ob die in den je\-weil\-igen Java Specification Requests
be"-schrieb"-en"-en Funktionalitäten umsetzbar sind wurden die folgenden beiden
Java Enter"-prise Edition Applikationsserver verschiedener HerstellerInnen für
die Um\-setz\-ung herangezogen. Es wurde dabei darauf geachtet möglichst
unterschiedliche Produkte auszuwählen. Dadurch soll herausgefunden werden ob die
Programmierschnittstellen tatsächlich standardkonform umgesetzt wurden. Dies um
aufzuzeigen ob die entwickelten Programmmodule tatsächlich ohne Anpassungen
vornehmen zu müssen auf beliebigen als standardkonform anerkannten
Applikationsservern einsetzbar sind.




\subsubsection{GlassFish}
%Haui oben bei Zielsetzung ebenfalls von der prototypenhaften Umsetzung
% sprechen.
Da es sich bei diesem Applikationsserver um die
Referenzimplementierung der Java Enterprise Edition Spezifizierungen handelt,
er kostenlos verfügbar sowie quelloffen ist und von Oracle angegeben wird dass
er voll Java Enterprise Edition 6 kompatibel ist wird er für die
prototypenhafte Umsetzung herangezogen. Es wird die Version GlassFish Server
Open Source Edition 3.1.2.2 (build 5) verwendet.



%Haui weiter oben bei Stand der Technik dann noch auf den Java EE 6 Standard
% verweisen wo steht das jeder voll kompatible Java EE Server JASPIC usw. usf.
% unterstützen muß. Weiters wird angegeben dass der Server JASPIC unterstützt
% (hier verweisen.)


\subsubsection{Oracle Weblogic}
Ein kommerzieller und nicht quelloffener Java Enterprise Edition
Applikations"-server der Firma Oracle Inc., welcher ebenfalls, von ebendieser,
als voll Java Enterprise Edition 6 kompatibel angegeben wird. Es wird die
Version 12.1.1.0 eingesetzt.








\subsection{Deklarative Berechtigungsprüfung}
"`Declarative security allows greater opportunities for application
portability because all the security issues related to the underlying
container and operating system are defined ... external to the application.
In addition, an application that makes use of declarative security is easier
to develop because security ... issues are managed outside the application"'
\cite[S. 75]{for-declarative-security}. Aus diesem Grund wird für die
vorliegende Umsetzung die deklarative Berechtigungsprüfung herangezogen.


\subsection{Java Authentication Service Provider Interface for Containers}
Aufgrund der Tatsachen dass es 

\begin{itemize}
  \item [a)]
  die standardisierte Schnittstelle für das Einbinden von selbst erstellten
  Authentisierungsroutinen, sowie zur Zuweisung von Rechten zu BenutzerInnen,
  sowohl der Java Platform Standard Edition als auch der Enterprise Edition ist
  \item [b)]
  auf Mitteilungsebene arbeitet und es daher alle eingehenden
  Anfragen an, sowie ausgehende Antworten von Java EE Containern, bearbeiten
  sowie manipulieren kann
\end{itemize}
 wird diese Schnittstelle für die prototypenhafte Umsetzung verwendet.
 


\subsection{Java Authentication and Authorization Service}

Durch die von dieser Schnittstelle

\begin{itemize}
  \item [a)]
  zur Verfügung gestellten Möglichkeiten die Authentisierung von
  Benutzer"-Innen, sowie dem Zuweisen von Rechten zu ebendiesen über eine
  Kon\-fi\-gu\-ra\-ti\-ons\-datei austauschbar zu machen sowie
  \item [b)]
  der Tatsache dass die Programmierschnittstelle standardisiert ist 
\end{itemize}
werden die Geschäfts"-applikationen, welche diese Schnittstelle ver"-wenden,
un"-abhängig von der Authentisierung sowie dem Zuweisen von Rechten zu
Benutzer"-Innen. Sie wird daher intern, von dem auf JASPIC basierenden Modul,
zur Authentisierung, sowie dem Zuweisen von Berechtigungen zu Benutzer"-Innen,
verwendet.




\subsection{JavaServer Faces}
Da JavaServer Faces eine strikte Trennung zwischen Anwendungslogik und
Darstellung bieten sowie der Tatsache dass Berechtigungen deklarativ und
getrennt in den Deployment Descriptoren erfolgen können wird dieses Framework
für die Umsetzung der beispielhaften HTML-Webanwendung herangezogen.





\section{Alternative Umsetzungsmöglichkeiten}
Folgende alternative Umsetzungen sind möglich.


\subsection{Andere Java EE Applikationsserver}
Die beschriebene Funktionalität muß mit allen voll Java Enterprise Edition 6
kompatiblen Applikationsservern umsetzbar sein da sowohl JAAS als auch JASPIC
verpflichtend von allen ApplikationsserverherstellerInnen zu unterstützen sind
wenn sie voll Java Enterprise Edition 6 kompatibel sein wollen
\cite[S. 148]{JavaEE-Spec} \cite[S. 159]{JavaEE-Spec}.




\subsection{Ausschließlich JASPIC}
JASPIC beinhaltet im Gegensatz zu JAAS selbst keine inhärenten
standardisierten Möglichkeiten Authentisierungs- sowie Rechtezuweisungsverfahren
%Hast du das weiteroben
konfigurierbar und zur Programmlaufzeit austauschbar zu machen. Eine
ausschließlich auf JASPIC basierende Umsetzung ist daher zwar möglich jedoch
weniger sinnvoll da die von JAAS bereitgestellten Möglichkeiten entweder
nochmals implementiert werden müßten oder verloren gehen würden.




\section{Nicht zielführende Umsetzungen}
Folgende Umsetzungen sind, aufgrund der definierten Zielsetzung, nicht
ziel"-füh"-rend.






\subsection{Programmatische Berechtigungsprüfung}
Da in Applikationen eingebettete programmatische Berechtigunsprüfungen nicht
angepaßt werden können ohne den Quelltext der Applikationen zu modifizieren kann
dieser Ansatz nicht für die Umsetzung herangezogen werden.

%http://my.safaribooksonline.com/book/programming/java/0596101422/j2ee-security/javaentnut3-chp-10-sect-3

\subsection{Applikationsspezifische Filter}
Da die beschriebenen Filter jeweils Teile der einzelnen Applikationen sind
können Berechtigungsüberprüfungen auch hiermit nicht angepaßt werden ohne den
Quelltext der Applikation abändern zu müssen. Daher kann auch dieser Ansatz
nicht für die Umsetzung herangezogen werden.



\subsection{Ausschließlich JAAS}
JAAS standardisiert zwar wie verschiedene Verfahren welche Authentisierung von
BenutzerInnen, sowie das Zuweisen von Berechtigungen zu ebendiesen, 

\begin{itemize}
  \item
  zur Verfügung gestellt,
  \item
  zur Laufzeit ausgetauscht
  \item
  und von Programmen eingebunden
\end{itemize}

werden können.
\newline
\newline
%
%Haui hier nochmals das eben nicht standardisiert wird wie automatisch
% aufgerufen und bei Containern. Beides überprüfen und Container weiter vorne aufnehmen
%
Jedoch nicht wie und unter welchen Umständen Java EE Container zur Laufzeit
diese Verfahren automatisch einbinden können. Hierfür gibt es von einzelnen
ApplikationsserverherstellerInnen zwar Erweiterungen. Diese sind aber spezifisch
für einzelne Serverprodukte, nicht standardisiert und daher nur auf den für sie
ent\-wickelten Applikationsservern einsetzbar. Darauf aufbauende Lösungen wären
daher nicht auf beliebigen Java Enterprise Edition Applikationsservern
einsetzbar.





\subsection{Java Authorization Contract for Containers}
Der Zweck dieser Schnittstelle besteht darin auf fein granulare und
anpaßbare Art und Weise, anstatt der Java Enterprise Edition Container, zur
Laufzeit zu entscheiden welche BenutzerInnen zu welchen Aktionen berechtigt
sind. Daher ist sie einerseits für die vorliegende Aufgabenstellung, aufgrund
der fehlenden Unterstützung für Autorisierung, nicht geeignet. Sowie
andererseits für die Umsetzung der notwendigen Funktionalität, aufgrund der
JASPIC sowie JAAS Schnittstellen, nicht notwendig. Sie wird daher nicht für die
Umsetzung herangezogen.





%-----------------------------------------------------------------------------
\section{Ergebnisse der Umsetzung}
%-----------------------------------------------------------------------------
Aus der gewählten Umsetzung ergeben sich die folgenden wichtigen Ergebnisse und
Zwischenschritte.


\subsection{Übergreifende Strukturen}
Aufgrund der Java Enterprise Edition Spezifikation ergeben sich die folgenden
wichtigen übergreifenden Strukturen.




%
%Haui
%Nicht vergessen hier irgendwo auf die Zielsetzung verweisen und sagen dass alle 
%Punkte erfüllt werden. Nochmals die Punkte irgendwie vielleicht kurz aufzählen.
%
\subsubsection{Die Klasse Subject}
Die Klasse "`javax.security.auth.Subject"' fungiert als Sammelbehälter für
alle für die Autorisierungsprüfung notwendigen Informationen zur betreffenden
BenutzerIn welche die Applikation verwenden möchte. Dem Subject können
ausschließlich Instanzen welche bestimmte Interfaces, siehe "`Das Interface
Principal"', implementieren übergeben werden.
 



%Weiter unten noch mit Subject ausbessern


%Später noch genau recherchieren das JAAS mehrere Subjects und JASPIC nicht.
%Wenn sicher das als Unterschied schreiben.

\subsubsection{Das Interface Principal}
Instanzen von Klassen welche das Interface "`java.security.Principal"'
implementieren repräsentieren alle einzelnen atomaren Informationen zu
BenutzerInnen im Rahmen einer Autorisierungsüberprüfung. Dabei kann
beispielsweise eine Klasse die Identität der BenutzerIn in Form eines
Primärschlüssels sowie eine oder mehrere andere Klassen die der BenutzerIn
zugewiesenen Berechtigungen enthalt\-en.



\subsection{JASPIC Spezifikation}
Die Umsetzung beinhaltet die folgenden die JASPIC Spezifikation betreffenden
wichtigen Eckpunkte.


\subsubsection{Das Interface ServerAuthModule}
Die Spezifikation definiert das Interface
"`javax.security.auth.message.module.Ser"-verAuthModule"' welches dem
Java Container als Schnittstelle dient. Alle auf die Spezifikation aufbauenden
Programmmodule müssen dieses Interface implementieren.


\subsubsection{Das Interface Callbackhandler}
Alle selbst erstellten Programmmodule können dem aufrufenden Container
Informationen über die Methode "`handle"' der Klasse
"`javax"".security"".auth.call"-back.Call"-backhandler"' übermitteln. Der
Methode müssen Instanzen des Interfaces
"`javax.""security.""auth.call"-back.Call"-back"' übergeben werden. So können
dem auf"-ru"-fen"-den Container durch Übergabe von Instanzen der Klassen
"`javax.security.auth.""message.call"-back.Caller"-PrincipalCallback"' und
"`javax.security.auth.message.call- \newline back.GroupPrincipalCallback"' die
Identität der aufrufenden Person sowie die Rechte der aufrufenden Person
mitgeteilt werden.


\subsubsection{Ablauf der Nachrichtenverarbeitung}
%Haui das immer noch überprüfen.
%Am besten in der Spezifikation nachsehen
Bei der Verarbeitung von Nachrichten werden jeweils die folgenden Methoden von
der das Interface implementierenden Klasse in der folgenden Reihenfolge
aufgerufen.


\begin{enumerate}
  
  \item initialize(\ldots)
  \newline
  Wird vom ausführenden Container immer zu Anfang aufgerufen um alle initialen
  Werte, d.h. die zu verarbeitenten Nachrichten selbst, etwaige
  Konfigurationseinstellungen sowie den Callbackhandler, übergeben zu können.
  
  \item validateRequest(\ldots)
  \newline
  Wird vom ausführenden Container mit Übergabe der HTTP-Anfrage sowie der
  HTTP-Antwort zum Zwecke der Überprüfung aufgerufen. Beide Übergabewerte können
  und sollen, so notwendig, an dieser Stelle manipuliert werden. Auch müssen dem
  aufrufenden Container an dieser Stelle die Identität der die Mitteilung
  übermittelnden BenutzerIn, sowie dazu gehörenden Berechtigungen, mitgeteilt
  werden. Weiters teilt die Methode dem aufrufenden Client/der BenutzerIn mit ob
  die Anfrage weiterverarbeitet wird oder nicht.
  
  \item secureResponse(\ldots)
  \newline
  Wird vom aufrufenden Container vor Übermittelung der HTTP-Antwort, welche
  mitsamt der Identität, sowie den Berechtigungen, der aktuellen BenutzerIn mit
  übergeben wird, aufgerufen. Dies bedeutet die Antwort an den Client bzw. die
  BenutzerIn kann vor der endgültigen Übermittelung nochmals überprüft und
  gegebenenfalls manipuliert und/oder unterbunden werden. Weiters teilt die
  Methode dem aufrufenden Client/der BenutzerIn mit ob die Anfrage
  weiterverarbeitet wird oder nicht.
  
  
\end{enumerate}







\subsection{JAAS Spezifikation}
Die Umsetzung beinhaltet die folgenden die JAAS Spezifikation betreffenden
wichtigen Eckpunkte.



\subsubsection{Das Interface LoginModule}
Die Spezifikation definiert das Interface
"`javax.security.auth.spi.LoginModule"'. Alle darauf aufbauenden Programmmodule
welche austauschbare JAAS kompatible Verfahren anbieten möchten müssen dieses
implementieren.






\subsubsection{Login Konfiguration}
%http://docs.oracle.com/javase/6/docs/technotes/guides/security/jaas/JAASRefGuide.html#AppendixB
Einzelne, das Interface "`LoginModule"' implementierende und somit JAAS
kompatible Verfahren anbietende und repräsentierende Programmmodule können in
Konfigurationsdateien für die spätere Verwendung registriert und zur Laufzeit
ausgetauscht werden. Hierbei muß ein Name für das Berechtigungsverfahren sowie
zumindestens eine Loginmodulklasse angegeben werden. Es können jedoch auch
mehrere die Loginmodulklasse implementierente Klassen zu einem Eintrag
hinzugefügt werden.
Diese werden beim Loginvorgang sodann nacheinander abgearbeitet.





\subsubsection{Die Klasse LoginContext}
Die Klasse "`javax.security.auth.login.LoginContext"' ist für aufrufende
Programme die Schnittstelle zu den jeweilig tatsächlich verfügbaren JAAS
kompatiblen Verfahren. Diese werden durch Angabe des Namens des
%Haui noch schreiben dass erst diese Klasse JAAS pluggable macht
Berechtigungsverfahrens, so wie er in der Konfigurationsdatei vorzufinden ist,
ausgewählt wodurch die dazu gehörenden Loginmodulklassen instanziert werden. Sie
bietet die folgenden Methoden an:

\begin{itemize}

  \item login()
  \newline
  Führt den Loginvorgang unter Verwendung der betreffenden Methoden, siehe
  "`Ablauf des Loginvorganges"', der jeweiligen Klassen aus. 
  
  \item logout()
  \newline
  Führt den Logoutvorgang unter Verwendung der betreffenden Methoden, siehe
  "`Logoutvorgang"', der jeweiligen Klassen aus.
  
  \item getSubject()
  \newline
  Gibt das Subject zurück.
  
\end{itemize} 

%Sie wird durch Angabe des Loginnames in
%der Loginkonfigurationssdatei





\subsubsection{Das Interface Callbackhandler} 
%Haui das hier nochmals überprüfen im Code
JAAS Module tauschen, ebenso wie JASPIC Module, jedoch mit Ausnahme des Subject,
mit den sie aufrufenden Programmen, im vorliegenden Fall mit der
JASPIC-ServerAuthModule kompatiblen Klasse, Informationen über die Methode
"`handle"' der Klasse "`javax"".security"".auth.callback"".Callbackhandler"'
aus. Dieser Methode müssen wiederum Instanzen des Interfaces
"`javax.""security.""auth.""callback.""Callback"' übergeben werden.


\subsubsection{Ablauf des Loginvorganges}
%Haui das immer noch überprüfen.
%Am besten in der Spezifikation nachsehen
Beim Loginvorgang werden jeweils die folgenden Methoden von
der das Interface implementierenden Klasse in der folgenden Reihenfolge
aufgerufen.


\begin{enumerate}

  \item initialize(\ldots)
  \newline
  Wird immer aufgerufen um alle initialen Werte, d.h. etwaige
  Konfigurationseinstellungen sowie den Callbackhandler, übergeben zu können.
  Sowie wird weiters das Subject welches befüllt werden soll übergeben.
    
  \item login()
  \newline
  Der eigentliche Loginvorgang wird durchgeführt.
  Das Ergebnis dieses jedoch bis zum Aufruf der Methode "`commit"' nur intern
  gespeichert.
  
  \item commit()
  \newline
  Das Ergebnis des Loginvorganges wird dem, durch die Methode
  "`initialize(\ldots)"' übergebenen, Subject zugewiesen und somit an die
  aufrufende Umgebung zurückgegeben.
     
\end{enumerate}

Sowie wird weiters, im Falle des Auftretens eines Fehlers, die Methode "`abort()
welche alle bisherigen temporären Logininformationen zu löschen hat, aufgerufen.


\subsubsection{Logoutvorgang}
Auch wird vom Interface "`LoginModule"' die Methode logout(\ldots) vorgegeben um
das Logout von BenutzerInnen zu unterstützen. Dies wird durch das Löschen der im Subject
vorhandenen Principals erreicht.






%Haui die oben beschrieben prototypenhafte HTML-Webanwendung auch kurz irgendwo
%ansprechen



%\subsection{Entwicklung}
%Haui hier müssen die Überschriften natürlich mit den Überschriften weiter oben
% übereinstimmen






\subsection{Einbinden notwendiger Libraries für Entwicklung}
Um mit der JASPIC sowie der JAAS Schnittstelle entwickeln zu kön\-nen muß das
Java Archiv "`javax.security.auth.message"' in die verwendete
Entwicklungs\-umgebung als Li\-brary eingebunden werden. Sowie, da im JASPIC
Modul auf Mitteilungen die über das HTTP-Protokoll übermittelt werden, zugegriffen
werden wird das Java Archiv "`javax.servlet"'. Beide Archive können zB im
"`modules"' Verzeichnis des GlassFish Applikations"-servers gefunden werden.



\subsection{Entwicklung des JASPIC Modules }
Bei der Entwicklung des JASPIC Modules ergaben sich die folgenden
wichtigen Zwischenschritte und Resultate.



\subsubsection{Definition und Initialisierung des "`ServerAuthModule"'}
Die Klasse "`DefaultServerAuthenticationModule"' implementiert das
vorgeschriebene Interface, speichert den vom aufrufenden Container
übergebenen Callbackhandler intern für die spätere Verwendung zwischen. Auch
setzt sie den JAAS Logincontext, siehe "`Setzen des JAAS Logincontext"'.


\lstinputlisting[language=Java]{figures/solely_new/JASPIC-one.java}




%
%Haui Weiter oben noch beschreiben dass die Lösung auf dem Auslesen des 
%Cookies besteht.
%Das ist wirklich wichtig.
%

\subsubsection{Setzen des JAAS Logincontext}
Der Logincontext wird durch Übergabe des zugehörenden Namens der
Berechtigungsprüfung aus der JAAS Konfigurationsdatei erstellt. Sowie weiters
durch den ebenfalls neu erstellten, zwischengespeicherten und für die
Kommunikation zwischem dem JASPIC und dem JAAS Modul zuständigen zweiten
Callbackhandler.


\lstinputlisting[language=Java]{figures/solely_new/JASPIC-getLoginContext.java}




\subsubsection{Überprüfen der Serveranfrage}
Die Methode "`validateRequest"' führt durch Verwendung des durch den
Logincontext zur Verfügung gestellten JAAS Modules und unter Verwendung des
zugehörenden Callbackhandlers die gesamte Authentisierung sowie die
Bereitstellung der Berechtigungen durch. Diese Informationen werden an den
aufrufenden Java Container, wiederum unter Verwendung des entsprechenden
Callbackhandlers, zurückgegeben.



\lstinputlisting[language=Java]{figures/solely_new/JASPIC-two.java}







\subsection{Entwicklung des JAAS Modules}
Bei der Entwicklung des JAAS Modules ergaben sich die folgenden
wichtigen Zwischenschritte und Resultate.


%Am Ende noch überprüfen ob du dich wohl nirgends mit Klasse und oder Interface Angabe vertan hast

\subsubsection{Definition und Initialisierung des "`LoginModule"'}
Die Klasse "`CoSessionLoginModule"' implementiert das
vorgeschriebene Interface und speichert in der vorgeschriebenen
Initialisierungsmethode den vom aufrufenden JASPIC Modul übergebenen
Callbackhandler sowie das Subject für die spätere Verwendung.



\lstinputlisting[language=Java]{figures/solely_new/LoginModule-one.java}



\subsubsection{Authentisierung sowie Holen von Berechtigungen}
Die Methode "`login"' stellt unter Verwendung des HTTP Cookies der BenutzerIn,
welches über den Callback "`CoSessionIdCallback"' welcher wiederum mit Hilfe des
Callbackhandlers "`DefaultCallbackHandler"' vom JASPIC Modul bereitgestellt
wurde, die Identität der BenutzerIn sowie ihre Berechtigungen fest. Diese Daten
werden jedoch nicht sofort an die aufrufende Umgebung retourniert sondern
intern, für die spätere Rückgabe, zwischengespeichert.
%Haui hier erwähnst du dass es mehrere Loginmodule geben kann
%Checken ob dies mit den anderen Informationen übereinstimmt
Auch wird über den booleschen Rückgabewert der Methode, im Falle dass die
BenutzerIn kein HTTP Cookie übermittelt hat, also noch nicht angemeldet ist,
über den Rückgabewert "`false"' die Abarbeitung des vorliegenden Loginmodules beendet
werden. 




\lstinputlisting[language=Java]{figures/solely_new/LoginModule-two.java}





\subsubsection{Auslesen des HTTP-Sessioncookies mittels DefaultCallbackHandler}
Der vom JASPIC Modul bereitgestellte CallbackHandler "`DefaultCallbackHandler"'
implementiert das vorgeschriebene Interface. Er kann weiters über eine
Hilfsmethode aus der intern gespeicherten, und ebenfalls vom JASPIC Modul, über
die Methode "`setRequest"' bereitgestellten, HTTP-Anfrage der BenutzerIn das
HTTP Cookie extrahieren. Dieses wird in Form des Callbacks
"`CoSessionIdCallback"' bei Aufruf der Methode "`handle zurückgegeben. Da
Callbackhandler beliebige Instanzen von Callbacks entgegennehmen können wird
intern eine Typüberprüfung mit dem "`instanceof"' Operator durchgeführt. Und im
Falle der Übergabe eines unbekannten, und somit nicht unterstützen, Callbacks
ein Fehler geworfen. So kann gewährleistet werden dass verschiedene Callbacks
die, und jeweils nur die, für sie bestimmten Daten erhalten.

\lstinputlisting[language=Java]{figures/solely_new/DefaultCallbackHandler.java}



\subsubsection{Übergabe des Cookies mittels CoSessionIdCallback}
Die Klasse "`CoSessionIdCallback"' implementiert das vorgeschriebene Interface
und dient einzig dem Zweck als Austauschcontainer zwischen den einzelnen Modulen
zu fungieren. Sie nimmt über die Methode "`setCoSessionCookieValue"' den
übergebenen Wert des HTTP Cookies zur Zwischenspeicherung entgegen. Sowie gibt
ebendiesen bei Aufruf der Methode "`getCoSessionCookieValue"' zurück.

\lstinputlisting[language=Java]{figures/solely_new/CoSessionIdCallback.java}




\subsubsection{Rückgabe des Subject mittels der Methode commit}
Die Methode "`commit"' setzt, aufgrund der in Methode "`login"'
zwischengespeich\-erten Daten, unter Verwendung der zugehörenden Principals das
Subject. Da sowohl das aufrufende JASPIC Modul als auch das JAAS Modul auf
dieselbe Spei\-cherstruktur im Hintergrund referenzieren wird das Subject so an
das JASPIC Modul zurückgegeben. Auch könnte über den booleschen Rückgabewert der
Me\-tho\-de, analog zur Methode "`login, über den Rückgabewert "`false"' die
Abarbeitung des vorliegenden Loginmodules beendet werden.
 


\lstinputlisting[language=Java]{figures/solely_new/LoginModule-three.java}



\subsubsection{Defintion der Principals}
Die implementierten Principals "`CoAccountPrincipal"' sowie
"`CoUserGroup- \newline Principal"' implementieren das vor\-ge\-schrieb\-ene
Interface, geben beide über die vorgeschriebene Methode "`getName"' den zugehörenden Wert zurück
sowie ermöglichen beide das Setzen dieses Wertes über die Methode "`setName"'.


\lstinputlisting[language=Java]{figures/solely_new/Principal.java}




%Änderung dieser Überschrift weiter unten jedenfalls nachziehen
\subsubsection{Definition verschiedener Loginmöglichkeiten}
%Haui die Überschrift nochmals überdenken
Damit die in "`Setzen des JAAS Logincontext"' beschriebene Berechtigungsprüfung
"`CAMPUSonlineAuthenticationModule"' instanziert werden kann muß diese der Java
Virtual Machine bekannt gemacht werden. Hierfür wird in der für den
Applikationsserver spezifischen Datei, siehe Kapitel "`Konfiguration und
Installation"' die Klasse welche das Loginmodul beinhaltet mitsamt dem Namen der
Berechtigungsprüfung in folgender Form angegeben.


\lstinputlisting[language=Java]{figures/solely_new/CAMPUSonline_jaas.config}


Anstelle des Wertes "`required"' können auch die Werte "`requisite"',
"`sufficient"' oder "`optional"' angegeben werden \cite{JAAS-config}. Dies ist
jedoch nur relevant für Berechtigungsverfahren welche mehrere Loginmodule
beinhalten.


%Haui weiter oben dann eben den Web Desktriptor erwähnen

%Haui
%Weiter oben schreiben das es xhmtl Dateien gibt in welchen das Layout in Form
% von XML beschrieben wird.
%Denn hier hast du ja xhtml
%Deploymentdescriptor muß weiter oben jedenfalls erklärt werden.

\subsection{Entwicklung der JavaServer Faces Applikation}
Die JavaServer Faces Beispielapplikation besteht aus zwei Webseiten welche im
xhtml-Format erstellt wurden sowie aus der Deployment Descriptor Datei
"`web.xml"'.

\subsubsection{Darstellung von Inhalten}
Die Seite "`index.xhtml"' stellt einzig und allein einen Willkommenstext dar und
dient nur zur Demonstration dass sie ohne entsprechende Berechtigungen nicht
aufgerufen werden kann.

\lstinputlisting[language=XML]{figures/solely_new/index.xml}






\subsubsection{Weiterleitung auf die Loginseite}
Die Seite "`forward.xhtml"' stellt die Nachricht dar dass die
BenutzerIn auf die Anmeldeseite weitergeleitet werden wird sowie führt diese
Aktion nach 2 Sekunden aus. Auch gibt sie der Anmeldeseite die Information,
welche Seite sich die BenutzerIn ursprünglich anzeigen lassen wollte, weiter.
Dies damit die Anmeldeseite auf dem entfernten Applikationsserver wieder darauf
zurückleiten kann.


\lstinputlisting[language=XML]{figures/solely_new/forward.xml}



\subsubsection{Absicherung mittels Deployment Descriptor}
Die Datei "`web.xml"' fungiert als Deploymentdescriptor und definiert dass die
einzelnen xhtml Dateien als JavaServer Faces Webseiten vom Applikatonsserver
interpretiert werden sollen. Wobei die Datei "`index.xhtml"' als initiale
Willkommensseite, wenn von BenutzerInnen keine spezifische Webseite angegeben
wird, angezeigt werden soll. Innerhalb des XML-Tags "`<security-constraint>"'
werden alle Webseiten der Applikation unter Verwendung des declarativen Java EE
Sicherheitsansatzes als ausschließlich von BenutzerInnen welche das Recht
"`ADMIN"' besitzen aufrufbar definiert. Diese Berechtigung muß in einem eigenen
"`security-role"' Bereich definiert werden. Sowie wird weiters innerhalb des
XML-Tags "`<login-config>"' angegeben dass sollten BenutzerInnen dieses Recht
nicht besitzen sie auf die Anmeldungsseite "`forward.xhtml"' weitergeleitet
werden, siehe "`Weiterleitung auf die Loginseite"'.
 
 
 

\lstinputlisting[language=XML]{figures/solely_new/web.xml}





\subsection{Konfiguration und Installation}
Folgende Konfigurations- und Installationsschritte sind, neben der Installation
der JavaServer Faces HTML-Webanwendung für die angeführten Java Enterprise
Edition Ap\-pli\-ka\-ti\-ons\-server notwendig um die beschriebene
HTML-Webanwendung mit den beschriebenen Softwaremodulen zusammen auszuführen und
einzubinden.



\subsubsection{Erstellen des Java Archives}
Um sowohl dem GlassFish als auch dem Oracle Weblogic Applikationsserver das JAAS
sowie das JASPIC Modul bereitzustellen werden diese in das Java Archiv
"`LoginModules.jar"' verpackt.


\subsubsection{Bereitstellen des Java Archives für GlassFish}
Das Java Archiv muß dem GlassFish Server in seinem Library Ordner
"`{glassfish-home}/glassfish/lib"' bereitgestellt werden damit er die
beinhaltenden Programmmodule ausführen kann. Wobei sich die Angabe
"`{glassfish-home}"' auf das Basisinstallationsverzeichnis des vorliegenden
Applikationsverzeichnis bzieht.




\subsubsection{Registrierung des JAAS Modules in Konfigurationsdatei für
GlassFish} Der GlassFish Applikationsserver stellt eine Standard JAAS
Konfigurationsdatei im Ordner "`{glassfish-domain-home}/config"' mit dem Namen
"`login.conf"' bereit. Wobei sich die Angabe "`{glassfish-domain-home}"' auf das
Basisverzeichnis der installierten GlassFish Domain bezieht. In dieser muß der
%
%Haui zu Ende kontrollieren ob der Kapitelverweis stimmt
%
Eintrag des Berechtigungsverfahrens, siehe Kapitel "`Definition verschiedener
Loginmöglichkeiten"' am Ende hinzugefügt werden.



\subsubsection{Konfigurieren des JASPIC Modules für GlassFish}
In der GlassFish Administrationskonsole muß im Tabulator "`Providers"' unter
"`Configurations -> server-config -> Security -> Message Security ->
HttpServlet"' die Schaltfläche "`Neu"' gewählt werden um das JASPIC Modul zu
registrieren. Wobei als "`Provider ID"' der Name "`JASPIC-Modul"', als
"`Provider Type"' der Wert "`server"', sowie als "`Class Name"' der voll
qualifizierte Name der Klasse "`DefaultServerAuthenticationModule"' angegeben werden müssen. 
%Hier das stimmt noch nicht
%Nochmals überprüfen und auch Screenshot nochmals machen
Sowie unter
"`Request Policy"' als "`Authenticate Source"' der Wert "`sender"' und als
"`Authenticate Recipient"' der Wert "`before-content"' ausgewählt werden müssen,
(siehe Abb.~\ref{GlassFish-conf}).

\begin{figure}[H]
    \includegraphics [width=12cm,angle=0]
    {figures/solely_new/GlassFish-conf.png}
    \caption{Darstellung Konfiguration des JASPIC Modules für GlassFish}
    \label{GlassFish-conf}
\end{figure}






\subsubsection{Konfiguration der Webapplikation für GlassFish}
Damit der GlassFish Applikationsserver die vorliegende HTML Anwendung in
Zusammenarbeit mit dem JASPIC Modul ausführt muß die Webapplikation hier\-für
speziell angepaßt werden. Es muß neben der Standard Deployment Descriptordatei
"`web.xml"' die für den GlassFish Applikationsserver spezifische
und daher nur für ihn geltende und von ihm interpretierte Konfigurationsdatei
"`glassfish-web.xml"' der Anwendung hinzugefügt werden.
In dieser muß beim Attribut \newline "`httpservlet-security-provider"' des
XML-Tags "`glassfish-web-app"' der Name des für die Applikation anzuwendenden JASPIC
Modules angegeben werden.


\lstinputlisting[language=XML]{figures/solely_new/glassfish-web.xml}


















\subsubsection{Anpassen der Java Laufzeitumgebungsvariablen für Oracle Weblogic}
Der Weblogic Applikationsserver stellt im Unterschied zum GlassFish
Applikationsserver keine Standard JAAS Konfigurationsdatei bereit. Auch benötigt
er zum Zeitpunkt des Startens der Domaininstanz die Information an welcher
Stelle für Applikationen notwendige JASPIC Module zu finden sind. Dies kann dem
Server nicht zu einem späteren Zeitpunkt bekannt gemacht werden. Daher
muß das von der Firma Oracle bereitgestellte Script zum Starten der
Domaininstanz in Bezug auf Startoptionen der Java Laufzeitumgebung angepaßt
werden. Hier\-bei muß darauf geachtet werden dass die notwendigen Modifikationen
keine Start\-angaben der ServerherstellerIn für die Java Laufzeitumgebung
abändern oder überschreiben sondern nur ergänzen. Hierfür werden für Unix
Betriebssysteme in das Script "`startWebLogic.sh"', zu finden im Ordner
"`{weblogic-domain-home}/bin"' zu Anfang die folgenden Befehle eingefügt. Wobei alle
Verzeichnisangaben relativ erfolgen. Die
Angabe "`{weblogic-domain-home}"' bezieht sich, wie auch im folgenden auf das
Basisverzeichnis der installierten Weblogic Domain.  


\lstinputlisting[language=Java]{figures/solely_new/startWeblogic.java}


Besonderer Bedeutung kommt hierbei die Abfrage ob die Variable "`CLASSPATH"' bereits Werte enthält zu. Denn
einerseits dürfen eventuell bereits von aufrufenden Umgebungen unter Umständen
darin gesetzte Werte nicht überschrieben werden. Sowie andererseits darf die
Angabe um für die ausführende Java Laufzeitumgeb\-ung korrekt interpretierbar zu
sein an dieser Stelle nicht mit einem Punkt enden. Dieser Punkt kann unter Umständen bei Aufruf
des Scriptes jedoch bereits von einer anderen aufrufenden Umgebungen gesetzt
worden sein bzw. wird unter Umständen erst von nachfolgenden Anweisungen gesetzt
werden.




\subsubsection{Bereitstellen des Java Archives für Oracle Weblogic}
Das Java Archiv muß daher im Ordner "`{weblogic-domain-home}/lib" des
Applikationsservers abgelegt werden.




\subsubsection{Registrierung des JAAS Modules in Konfigurationsdatei für
Oracle Weblogic} 
Im Ordner "`{weblogic-domain-home}"' muß weiters die Datei "`jaas.conf"' mit dem
in Kapitel "`Definition verschiedener Loginmöglichkeiten"' beschriebenen Inhalt
erstellt werden um das JAAS Modul zu registrieren.



\subsubsection{Konfigurieren des JASPIC Modules für Oracle Weblogic}
In der Oracle Weblogic Administrationskonsole muß unter "`Home -> Domain ->
Registerkarte Security -> Unterregisterkarte JASPIC"' unter der weiteren
Unterregisterkarate "`General"' die Option "`Enable JASPIC"' aktiviert werden um
JASPIC Module ausführen zu können, (siehe Abb.~\ref{Weblogic-conf1}). 

\begin{figure}[H]
    \includegraphics [width=12cm,angle=0]
    {figures/solely_new/Weblogic-conf1.png}
    \caption{Darstellung Aktivierung generelle Ausführung von JASPIC Modulen bei
    Oracle Weblogic}
    \label{Weblogic-conf1}
\end{figure}



Sowie weiters in der Registerkarte "`Authentication Configuration Providers"'
auf gleicher Ebene über die Schalftfläche "`New"' die Option "`Authentication
Configuration Providers"' ausgewählt werden um das entwickelte JASPIC Modul zu
re\-gistrieren. Hierfür werden für "`Name"' der Wert "`JASPIC-Modul"' und als
Wert für "`Server Authentication Module Class Name"' der  voll qualifizierte Name
der Implementierungsklasse "`DefaultServerAuthenticationModule"'
angegeben, (siehe Abb.~\ref{Weblogic-conf2})


\begin{figure}[H]
    \includegraphics [width=12cm,angle=0]
    {figures/solely_new/Weblogic-conf2.png}
    \caption{Darstellung Konfiguration des JASPIC Modules für Oracle Weblogic}
    \label{Weblogic-conf2}
\end{figure}





\subsubsection{Aktivierung JASPIC Modul für Webapplikation bei Oracle Weblogic}
Um die vorliegende Webapplikation über das entwickelte und registrierte JASPIC
Modul abzusichern muß es dieser noch zugewiesen werden. Hierfür muß die
Applikation unter "`Home -> Deployments"' ausgewählt werden. Sowie in der
folgenden Ansicht zuerst die Registerkarte "`Security"' gefolgt von der
Registerkarte "`JASPIC"'. In dieser Übersicht muß für "`Authentication
Configuration Provider"' das zuvor registrierte JASPIC Modul "`JASPIC-Modul"'
ausgewählt werden, (siehe Abb.~\ref{Weblogic-conf3}).



\begin{figure}[htbp]
    \includegraphics [width=12cm,angle=0]
    {figures/solely_new/Weblogic-conf3.png}
    \caption{Darstellung Aktivierung JASPIC Modul für Webapplikation bei Oracle
    Weblogic}
    \label{Weblogic-conf3}
\end{figure}






\subsubsection{Konfiguration der Webapplikation für Oracle Weblogic}
Damit der Oracle Weblogic Applikationsserver die vorliegende HTML Anwendung in
Zusammenarbeit mit dem JASPIC Modul ausführt muß die Webapplikation hierfür
speziell angepaßt werden. Es muß neben der Standard Deployment Descriptordatei
"`web.xml"' die nur für den Oracle Weblogic Applikationsserver spezifische, nur
für ihn geltende und nur von diesem interpretierte Konfigurationsdatei "`weblogic.xml"' der Anwendung hinzugefügt werden.
Dies um die im Standarddeploymentdescriptor definierte Rolle den vom Weblogic
Server geforderten Principals zuzuweisen.


\lstinputlisting[language=XML]{figures/solely_new/weblogic.xml}





 

%Oder doch nicht
%Haui wenn dann am Abend als letztes machen 
%\subsection{Systemarchitektur}
%Haui
%Ja hier jetzt auch schönes Image machen JASPIC - JAAS - Browser - J2EE Server
%usw. usf.







